|
Retrieving content from a database with a SQL statement
causes fewer problems than retrieving the data manually from a
database. A dynamic site keeps content fresher. Updating
static HTML pages across a site is not difficult, but it is a
specific talent and it is time consuming. If you need to keep
your site fresh with new news, however, it is easier to insert
that content in a database than to change each page manually.
With a dynamic site, once a page is live, you can change
its content easily. If you were updating a static page,
however, an HTML professional would have to download the page
to a local machine, edit it, and then re-post it. In a dynamic
site, the document originator simply goes to a web page,
selects the record with the error, and changes it. The next
time any user accesses the page, the change is in effect.
There is no need to coordinate teams or download and upload
files. And best of all, it reduces the number of hands
touching the page, which reduces the chance of unintentional
changes or problems.
Of course, dynamic sites also create opportunities for
e-commerce and e-business. The most obvious benefit of a
dynamic site is that you can add e-commerce functionality to
your site, such as a shopping cart, auctions,
business-to-consumers and business-to-business resources such
as threaded discussions, indices, or searches. Once your
content is in a database, you can do anything you like with
it, and your offerings can grow without having to rip up your
whole site.
Once you decide you want to make your site dynamic, you
have a lot of research to do. Here are some issues to consider
when you decide to make your websites dynamic: |
Planning
for your needs ahead of time
Survey your customers
and prospective customers. Know what your customer is
doing on your site, not what they say they are doing.
To find out what your users are doing, watch them. Be prepared
to invite users to your facility or go to their location.
Invite users that like your site and those who have complained
about your site. Also, watch users of your competitors sites.
Assign the users tasksfor instance, 10-15 simple tasks, such
as finding a particular product, finding a place to mail a
comment, finding a phone number of someone that will answer a
question, finding a location, and searching for a name or
article.
What do they like? What do they dislike? Why and how can
you change that? What do they spend time on? Would a
particular page be ideal for putting related products,
advertisements, or special announcements? What pages do they
go back to, over and over? What pages do they never visit? (An
unvisited page might hold information they need to decide on a
purchase. In this case, knowing this information can help you
give higher exposure to that particular page or section of the
site.)
Another way to find out what a users like is to ask them to
take a survey. To increase the amount of submitted surveys for
an accurate sample, give the survey responders a gift.
Getting information
Evaluate the information you collect and think about
implementing it in your development plan before making any
other decision. Once you know what your customer does on your
site and what they want to do on your site, you are ready to
take the next step.
How much data do you want to publish? How many users will
access the site and how many concurrent users will you have?
This determines whether you need an e-commerce solution.
Now that you can estimate how robust your system needs to
be and how busy it is going to be, you can start planning your
service. Hosting
First, are you going to
host the site yourself onsite or offsite at an ISP? If you
plan to host it yourself, you must provide backups and monitor
security.
You must also buy hardware and software. You must have
redundant systems in case one or some of your servers fail.
You will need to have a high bandwidth connection to the
Internet. These are big expenses and require staff to set up
and manage. If you decide to host with an ISP, however, then
you pay them to perform the tasks listed above. This costs
more initially, but saves you costs in staff. With an ISP, you
pay professionals, so you will not have to train staff how to
install and maintain your systems.
Once you know where you would like to place the site, think
about what database to use. Picking a database
If you are
going to have a low volume site and you are developing the
site and database yourself, Microsoft Access and FileMaker are
the two most popular choices. Both databases are easy to use
and both have a large amount of aftermarket books written
about them. If you use Microsoft Access, you can use any of
the dynamic server languages, such as ColdFusion, ASP,
ASP.NET, JSP or PHP. If you use FileMaker, look at Lasso, from
Blueworld; you can develop on either a
Macintosh or a Windows machine.
If you have a higher volume site and can do more technical
workor if your ISP supports it, you might use MySQL, which is
very popular and quite powerful.
On the Enterprise application level, look at Oracle, Sybase, Microsoft SQL Server, IBM
DB2, or Informix. These choices cost the most, but
give you the most robust solutions and the highest
reliability.
In addition to selecting a database, you must learn
structured query language(SQL) to select, update and delete
information in the database. I recommend Teach Yourself SQL in 10 Minutes by
Ben Forta and published by Sams Publishers. Luckily, using SQL
is easy.
Finally, become familiar with creating and designing
databases. This is a skill set that you will develop over
time. However, it is important to realize that a
well-researched database schema contributes to better
application performance. Research your problem and apply that
research in a solid data model. Research entity-relationship
modeling; database normalization; and conceptual, logical, and
physical database design to start with. Choosing an application server
Once
you have chosen the database, you can select a server language
and application server platform, which is the component that
serves the dynamic pages. I covered the selection of server
languages in a
previous column, so I will not do so again here other than
to say Macromedia
ColdFusion MX is an excellent choice that is easier to
learn than the others. ASP is everywhere, and you will have no
problem finding a host that supports it. ColdFusion
MX, ASP.NET and JSP/Java 2 Enterprise Edition (J2EE) are
ideal language options on the enterprise and mid-range
enterprise level. PHP is the fastest growing server model.
If you decide to use JSP, you must also choose the
application server. The Macromedia J2EE server, JRun 4, is
a good choice, as is ColdFusion
MX for J2EE (ColdFusion MX is now available on the J2EE
platform) as well. There are also free servers like Tomcat for
Apache, and high-end servers such as BEA WebLogic,
Sun-Netscape iPlanet, Oracle OAI, Borland, Unify,
SilverStream, and ATG. Again, select your application server
based on your site's traffic volume and the needs of your
business or client.
Now you are ready to create your site. Organizing workflow, processes and your
team
When you create your site, first establish a
workflow for your team. Keep it as simple as you can because
teams are not likely to adhere to complex workflows. Once you
create the workflow, be prepared to change it, but
never violate it.
That is, if you find that there is a situation that your
process does not cover, change the process, notify everyone
that the process has been changed, and get their consensus. Do
not simply solve the problem without updating the workflow.
This prevents you from having to reinvent a process for fixing
the same problem. Keep accountability for your development
work. If there are problems, it is costly to fix problems that
are not well documented.
To set up a workflow in your team, ensure that you set up
regular intervals to check your work and confirm it with your
customer. Taking the time to monitor and check in with your
customer prevents problems. Fixing problems earlier costs a
lot less than if you wait. Since workflow, processes and
organization of the team is a big topic, I recommend that you
study the project
management section of the Macromedia site for an
overview. Testing and
production
Create your servers and sites locally
and on a staging server. You should be able to test the site
as you work. On the staging server, a QA professional who is
not part of the day-to-day site creation should review your
site. He or she is more likely to catch problems or to try to
access invalid information or choices than the developers.
Test the site on a number of operating system platforms and
browsers.
Using a staging server is very important. As your team
grows, they should not have direct access to the production
server that is serving your site to the public. For instance,
if someone on your team were to make a small mistake on an
index page then upload it, it could knock your whole site out.
If the web development team posts files to the staging server
and then tests the page, you can catch problems before they go
live. You may also want to look into file and code versioning
software, such as Perforce to prevent developers from
overwriting each other's work.
Once your workflow and servers are set up, prototype your
site. Create it quickly on a machine, or mock it up on paper
or index cards. Present the mock-up to as many users as you
can and ask them to perform the same tasks you asked them to
do in the beginning of this article, when you isolated the
issues you were going to work on. If you discover flaws in the
site structure, you can fix them before site production.
Once you finish your prototype, refine it to templates
and create a data flow. Run one more set of tests in-house
with the tasks requested previously.
Assuming it all works, you are now ready to publish your
site from the staging server to the production server. And
you're ready to begin planning your first revision.
Once your customers or your client's customers work with
the site, they are going to find a number of things
to change. Be prepared and budget time and money for the
revision.
Application architecture and
coding best practices
Once you have some initial
coding under your belt, look into best practices and how to
architect dynamic web sites. While this is a more advanced
topic, it is worth mentioning here. A common problem
developers have in the dynamic realm is creating what
programmers call spaghetti codecode that is not well
organized, hard to read, and susceptible to bugs. To avoid
spaghetti code, learn about design patterns and application
architecture. Luckily, the Macromedia Designer & Developer
Center has an architecture
topic page that can help you learn about best coding
practices.
Congratulations, you are now
dynamic. |
.gif){kind=tracking}
